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ABSTRACT 


This thesis develops a concept for the simulation of 
command and control networks. The concept is based upon 2a 
model of the essential funetions of command and control 
systems and networks of systems. The model is used as the 
basis for discussion of network performance eavaluation, and 
the performance characteristics of concern form a basis for 
Buemisimurat ton architecture. The simulation concept is 
based upon a distributed simulation capable of utilizing a 
wide range of network node simulations ranging from manuai 
procedures to manned simulators to fully automated 
emulatorn:rs. The Simulation Sis Both flexible and 
transportable due to it's residence within a computer based 


distributed environment. 
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EB. INTRODUCTION 


A. BACKGROUND 

Several joint programs have been created in the past in 
order to answer questions regarding the interactions among 
the systems that comprise a command and control network. 
Mmeae inelude programs suth as Tactical Air Control 
Systems/Tactical Air Defense Systems (TACS/TADS). Joint 
MmreerOpe@rability of Tactical] Command and Control Systems 
CJINTACCS), and [Identification Friend, Foe, or Neutral 
ler NN). These programs have been acterized by several 
Suem@tiart types of shortcomings in their examination of the 
systems involved. 

The first set cf problems are those concerned with the 
Gommonality of the test systems used to conduct the network 
Pe soe ng . A common set of atr control and air defense 
systems are examined ay each of the above programs. In 


fact, the JINTACCS program assumed the mission of the 


mMmrGesrraAOsS program. Despite these obvious areas of 
Severidadpoing interest, wach of the programs required an 
entirely separate, but functionally similar, test systen. 


As a result of the inability to share the necessary test 
Capability, millions of dollars of development effort was 
repeated for each program. More timportantoly, ithe 


mesommeion of the underlying questions and operational 





peoblems wis delayed for several years whil@ the teste 


system was developed. 


A second set of problems are those concarning the 


staffing of these programs. Each of these programs has 
only a small staff. The full time job of this staff is to 
plan, conduct, and analyze tests of the target systems. ie ek 


order to accomplish these functions, the staff must make 
decisions regarding a test scenario, experimental desian, 
and data analysis. PeeGeclgning ptheuscenario, drolficiena, 
must Be maintained in the operational doctrine and tactics 
of each of the systems under test, network procedures, 
limitations and distortions introduced by the simuiations 
used for the test, and especially, the threat that can 
Mmeatiasticgatliy be @wpected from the opposing farces. 
Personal observation would indicate that even the most 
fmranmivy  aqualif ted individuals tend to fose their proficiency 
in many of these areas after being assigned tc one of the 


programs for a period of time. 


B. SCOPE 
ee Purpose 
MeneeeepUrpmese af this thesis its €5 DPre’sent & 
structure for simulating networks of command and control 
systems which alleviates the above mentioned problems 
Although the approach that is presented may b5e applicable 


to many similar problems at multiple levels of detail, it 





Has" been developed for a gnecific case. The development 
and the presentation here is focused on the examination of 
networks of tactical command and control systems. Since 
the emphasis is on the interactions among the systems which 
cemprise networks, there was no attempt to incorporate a 
capability to examine the internal mechanics of individual 
sy¢etemsi. 
78 Level of Presentation 

The presentation of the methodology will be given 
at‘ the laveal of a conceptual operating system task. A 
specific implementation for a given suite of equipment will 
na«* Be provided. The presentation will give descriptions 
Sueepcumetrond!t characteristics, rather than specific methods 
Pot Simpleméenting these functions. In many cases, tne 
~“iliausible or Best implementation will be highly dependent 


upon the equipment selected. 


oe ORGANIZATION 

Sections II and III will present a model of command and 
control networks. The model that is developed will be 
dire ted “toward identitying and understanding those 
elements of a command and contro! system which influence 
the characteristics of networks. ImeSe@et ion IV, this model 
will be used as the basis for discussing the evaluation of 
command and control network performance. Sections V 


through VIII will develop a simulation environment based 
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Mmomom che modveel of Sactions If and III. The environment 
will Be a computer based environment, but will be developed 
consistent with the idea of accommodating useful manual and 
semiautomated techniques inte the simulation. The 
procedures and policies whirth must accompany the 
methodology will be presented in Section I[&4. And finally, 
Section X¥ will summarize the results of the previous 


sections. 


toy 





|G Ces MODEL OF A COMMAND AND CONTROL SYSTEM 


Ks. FUNCTIONS OF A COMMAND AND CONTROL SYSTEM 
A. What is Command and Control 

With the recent focus on Command and Control, there 
would honefully be a universally acceptable definition or 
concept of what command and control is. Wnt ol cua Ge way, 
Mmmer@ is not. Therefore, virtually every paper that 
addresses the area of command and controi must define what 
the author perceives the subject to Be. Rather than taxing 
mmmenmragrmal approach of listing numerows conflicting 
definitions and attempting to find the common elements, let 
us look at the functions performed “by a command and control 
system. Pie tcnis Manner, tt ts possible to gain a feel for 
a command and control system without being unduly bdoungd oy 
aeemeraqoroeus definition. 

Ze Determine the Environment 

Mmer £Lirst function sperformed by a command axe 
control system is a determination of the state cf ifs 
environment. This may be accomplished in a number of ways. 
The system may employ a radar unit to odDServe air and 
surface targets, or sonar to track underwater targets. ie 
May receive digital data from other systems. In many cases 
this perception of the, system's environment can be very 


Sammie, such as an individual scanning an area with his 


LZ 





eyes. His last example highlights a very important 
Soncept. Note tnrat although the equipment that comprises 
many command and control systems usually receives the most 
emphasis in descriptions and analyses, a command and 
contrel system dees not have to be made up of computers and 
Sophisticated sensors. It could simply be a platoon 
commander with his compass, map, notebook, and radio. 
oe Formulate a Decision 

Having formulated an impression of its environment, 
the system must formulate a decision based upon this 
Pmoression. The decision reached could be to ignore the 
environment nnti’. a change of tnterest occurs. The system 
moteur dmcarde not to act upon the information which it has 
gathered, out to forward the data to another system for 
possibd/ie action, or to hold it for future reference. And 
era. v, emmee System may decide that some action, such as 
engagins 2 target, may Be required tin response to the 
environment. Of scoucse "somo inagtions of these decisions, 
Sarcoma Setecking action and forwarding the tnformation are 
also posstiGle. 

41. Sommunicate the Decision 

Omce 2 decision other than to tgnore the 
information has been made, it must be acted on. Theis 
requires the system to be able to communicate with other 
systems and/or to communicate with fire and maneuver units. 


Note that in an air defense missile battery, the missiles 





themselves are part of a weapons system and would not be 
part of the command and contre! system. However, this fire 
unit is very closely Linked to the sutnut of the command 
and control system's decision. Neither the command and 
control system, nor the fire unit would be effective 


without the other. 


B. ELEMENTS OF A COMMAND AND CONTROL SYSTEM 
Paeporeder §“to accomplish the functions of d@itermining the 
emvrrtronment, formulating a deciston, and «commeunicating the 


decision, a command and control system can be considered as 


Being composed of five elements: a set or Sersors, a 
@eecision algorrthm, a local data base, & method of 
communication, and some form of feedback. “Vihese szlements 


are shown in Figure 1. 
ios Sensocs 

The term sensors brings to mind im2aues of radars 
amamsoohisticated intelligence equipmen:. But sensors 
include all methods of observing the system's environment, 
from individuals to electronics. Im eadd1tion, tt is useful 
to consider radio receivers as S@enSOrS. nis, DOInts out 
that sensors are used to form an impression of all aspects 
of the environment. Friendly forces and neutral aspects 
such as weather are as important to the perception of the 
environment as are the aspects associated with enemy 


forces. The receipt of reports and data from other systems 
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Sensors 


Environment 


Decision _, Data 
Algorithm Base 


Communicate 
Decisions 


FIGURE 1. Elements of a 


Command and Control System 





aré also sensor inputs to the system. Sensors may be 
Pease iT OHeration, oar they may Be dynamically controlled 
Baw time GeEcrsion algorithm. An air ee system can 
Toca mievwemcmoloy both acquisition and fire control radars 
The acquisition radar acts as a Static sensor, reporting on 
Spmimeeuracks within a f{ixs’ed coverage. However, the fire 
G@eomeerOls tcadar 1S used to track specifie targets for 
engagement. The targets to be tracked are designated By 
the fire control system and thus the sensor is dynamically 


controlled. 


Ls} 





Z. ecgision Aigorithm 
GWrer dmecisicon algorithm umed by a systwem is 
generaily the most difficult portion of a system to define. 
meets. a COmplivexe function of people, training, morale, 
procedures, doctrine, and equipment performance. Even when 
the decision algorithm appears to be solely the judgment of 
a single commander, it is usually influenced Significantly 
by the manner in whith the sensor data is manipulated after 
receipt and prior to presentation to the commander 
ie Data Base 
Command and cecntrol systems employ a data base in 
order to store information deferred for future reference 
and to aid in the decision algorithm. This data base may 
Be composed of an automated data base system, maps, 
Geeerret avs, Or Alottimg boards. In systems involving 
personnel, it also inecitudes the experience and knowledge of 
Gem rnearyi dua is . 
4. Method of Communication 


Communication of deersions out of the system 


Piemsuaesmelectrconic transmitters, but it also includes 
verbal commands and reports. When “command by exception" 


procedures are included, such as those adopted for fire 
Beq@westu cOoOOrdination, a failure to communicate can also 


constitute communication of a decision. 
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a2 Feedback 

fm order to be an ef fect i wee cwomstence <ceecmwedue a 
command and control system must inciude faedback to 
determine the impact on the environment as a result of the | 
system actions. Note that this feedback can be considered 
as a special component of the sensor inputs. Examplas ocef 
feedback include explicit feedback, such 25 See £ Teqen 
Maneuver units, and implicit feedback, such as radar 


observation of a change in an aircraft's speed or heading 


ce. COMMAND AND CONTROL SYSTEM ENVIRONMENT 

The discussion so far has centered on what functiecons 
and elements comprise a command and control system AS ean 
be deduced from the preceding discussion, a command and 

@ 

SrommeterOt system is intimately tied to itS environwmeenre . 
Mereercee tbrore, adisecussion of the components of tire 
envitonment is now necessary. 

ee Communications 

As has been stated, communications receivars should 

be considered as sensors. Let us How constitder tre 
environment as a system using the model which has been used 
to describe the command and control system. Plong thas 
line of reasoning, the communication information received 
by the command and control system can Be considered as an 
output of the environment system. By the same argument, 
the output of the command and control system decision can 
be regarded as a sensor input to the environment systen. 


Le? 





2 .. Perception versus Truth 


Continuing to consider the environment as 2a System, 
the data base can be considered to be the parameters of the 
real environment. However, the environmental parameters 
sensed By the command and control system are seldom totally 
accurate, and at best comprise oniy a small subset of the 
total parameters. Therefore, the decision process in the 
environment system can be considered to act upon the 
environmental parameters and produce an output to the 
command and control system. 

oe Envirconmental Dynamics 

foie Senvircronment is not a static entity. It has 
Gayemamic characteristics that are due to the interaction 
with the command and control system and ones that are due 
to influences external to the command and control systen. 

a. External Influences 

Dynamics due to external influences are changes 
such as the movement of units that are not controlled by 
the command and control system and communications inputs to 
the system. 

Se. Response to Command and Control System 

The movement of units in response to commands 
from the command and control system and the resolution of 
engagements initiated by the command and control system are 


examples of dynamics due to the command and control system. 


18 





Both types of environmental! dynamics can be 
thought of as direct resuits of a decision algorithm within 
the environment which responds to inputs from both the 
command and control system, and trom other external 


sources. 


D. GENERIC MODEL 

The model presented so far is generally the same basic 
model of a command and contrci system that ! have observed 
in most of the discussions and Literature on command and 
@Semtrol. The only difference lwes in the consideration of 


tself. In this thesis, the 


4 


the environment as a system 


¢ 


emphasis is on the modeling, simulation, and evaluation of 


networks of systems, not the tndividual systems. Dm ot hes 
context, a much sitmpler model +: a single system can be 
used. Mmr1s model is given in fiyure 2. PAG fer Got ak an 6 Go; 


this model appears to Be too simplistic to be of any use. 
The decision algorithm and the data 3Sase have been merged 
into a single block, and the feedback element has bdDecome 
Just one of several input/output paths, with no explicit 
correlation shown. However, as will be developed in 
subsequent sections, the only aspects of the single system 
which are of ceal importance in the context of networks of 
systems is the understanding that there is a finite set of 
inputs to the system from the environment, and that there 


Meoauercor mt te set of outputs from the system to the 


ie 





Environment 


moURE 2. 


External 


Influences 





Model of a Generic System 


anvironment. It is also important to recognize that while 


the system reacts only 


to the environment, the anvironment 


reacts to influences external to the system. 
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Melek. MODELING A NETWORK OF COMMAND 


AND CONTROL SYSTEMS 





in this section, the model of an individual command and 
contrat systen which was developed in Section II will be 


extended tc address networks of systems. 


A . A CLASSICAL MODEL 


Consicer a network of four systems, such as air defense 


systems interconnected by both direct communications links 
and By a switched message system. Figure 3 shows how this 
mer athee@ment would typically be portrayed. This type of 
reopreszntation is a digraph with decision elements 


represent«d as nodes, and communications paths portrayed by 
Srach edcyeg. 


Lx System Nodes 


Taree types of nodes are used in the graph. Baca 
9f the four systems is a single node. im addition, the 
communiec«gztiosns switching system, and the external 


environment are represented By distinct nodes. 
oe: Communications 
Communications paths are modeled as edges in the 
gtaph. However, the switched communications requires 
gasicuimset OS tow be made, and thus it is conveyed as Both 
edges, representing the inputs and outputs, and as a node, 
representing the switching algorithm. 


z21 





Environment 


System 





External 
Ir fluences 


ee ee 


Message System 
Sein D 


FIGURE 3. Classical Model of C* Network 


3 Environment 
The environment represents ail of the items 
presented in the last section, escent the communications 


Mentioned above. 


Be AN ALTERNATE APPROACH 

This type of model suffers from two problems when used 
as a general model of a network of command and control 
systems. Perc sots, it 15 mot realiy tlezibie. Each of the 
systems (nodes?) has two types of edges, those that 
represent communications links, and those which represent 


interactions with the environment. When a system is added 
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to or deleted from the network model, the model used for 
each node must be updated to reflect the changing edges 
representing the communications. Secondly, it is not 
compatible with the generic system model shown in Figquirerc . 
Figure 4 presents an alternate model for representing this 


network arrangement. 





Environment 


TTT 


System | |System System | | System 
- B E D 





External 
Switch | Influences 


FIGURE 4. Modified Model of C* Network 


Oe Linkages as Part of the Environment 


In this model, the linkages between systems are 
modeled as inputs from the environment to the systems and 
as outputs from the systems to the environment. Note that 
each interconnection is only in one direction and that each 


system interacts only with the environment. The model for 





each node can be viewed as in Figure 2. In addition, since 
there are no direct interconnections between systems, there 
is no need te change the model of the existing systems when 
a system is added tc or deleted from the network, or the 


communications iS taarranyed. 


- Communicatrons 





in this model, it is necessary to enhance the model 
of the environment in order to convey all of the informaton 
BOounmwd in the, model of Figure 3. Soeciticaliy, the 


environment decision algorithm must include derision rules 
Mommie TOULing of communications data from an input to the 
environment ts tne appropriate output to a system. The 
Best way to visualize the way in which the environment must 
Be modeled is to examine the entire model from the 
perspective ofr the enviconment, as it views a single 


system. 


ee THE EXTERNAZXL VIEW 
1 Communications from the System 
The communications coming from the system can Be 
viewed simply as inputs to the environment, as in the 
Single syst2am mode: . The main point to be considered is 
that the system simply sends the data to the environment 
via one of its output paths. It is not necessary for the 


individual system model to know the destination of the 


faeeaeewoermer than a possible routing indicwtor tor a 
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switched communications system. Once the data reaches the 
environment model, it can be routed to the input of another 
system model, or it could be acted upon entirely within the 


environment model. 


4 


Le Communications to the System 


The communications into the system are provided by 
the environment without the individual system model having 


to know the source, other than a possible indicatorx, such 


as a from data field, in the communicated information. O42 
course, the system also knows which sensor received the 
Sommunication. Thev environment can -obtain the data trod 
erther of two sources. It can be generated internally te 


the environment model, or it can be obtained 8S input trom 
one of the systems. Note that in the case whera the data. 
is obtain from a system, it ean be considered as an 
external influence to the environment from the single 


system perspective, as in Figure 2. 
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LVi: COMMAND AND CONTROL NETWORK 


PERFORMANCE EVALUATION 





This section will examine how the performance of a2 


network of command and control systems can be evaluated. 


A. A RESPONSE ORIENTED EVALUATION 
In Section II, a command and control system was defined 
as a system that makes a decision based upon a perception 
Pieetieswenmvironment, and then communicates this decision. 
The same definition can be applied to a network of systems. 
The only real difference is that a network of systems 
¢hould hopefully be able to use the increased assets 
inherent toot eeene twor ky to devetop a iO re Gace urate 
mereeptronm, thus yielding a “better™ decision, and be able 
fo communicate decisions more effectively. 
De A Stimulus and Response Model 
Command and control systems and networks as they 
have been defined herein are an example of a stimulus and 
response system. The systems take their perception of the 
anvironment as a stimulus and respond with a decision. The 
stimulus and response can be traced By examining the data 
Passing between the systems and the environment. The 
stimulus is the data input from the environment, and the 


response is reflected in the data passed to the environment 
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by each system. Ehe set comprmasgrad ofall of the inputs to 
all of the systems constitutes the input to the network, 
and the set of outputs from «1! of the systems constitutes 
the response of the network. Generally, a zine stimulus 
from the environment wiil result in a response from one 
system, which is provided, via the environment, as a 
stimulus to another Systen The second system will then 
generate a response, and so cn until the output of a system 
is sent to the environment and is not passed to another 
system. in this case, the network can be evaluated by 
@ezamining the final respons@ compared to the initial 
stimulus. In evaluating networks, two properties of the 
response shoutd be considered; s:ts correctness and its 
timeliness. 

( Correctness of Resveonse 


Based upon the evalwator's knowledge of the raat! 
Bervertrg@mment, often rceferrem to as "ground truth", a 
determination can Be mada as to the most appropriate 
response for the network ta make Note that even if the 
stimulus remains constant, different responses may De 
expected depending upon the purpose of the evaluation. Tf 
Pimesnopyective is to develop tactics or doctrine, the 
response should be considered based upon its contribution 
to the achievement of a set of operational objectives. 


However, if the evaluation is made to determine the 


performance of a network within a given scenario or plan, 
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the existing doctrine and tactics must be used ag one of 
the measures of the correctness of the response, instead of 
as a variable. 
<i Timeliness of Response 

Each response has an associated time value. This 
response time is the time from the occurrence of the 
stimulus to the communication of the final response. The 
meaning of a specific time value must be weighed with 
respect to the value of the stimulus. A decision to assign 
a weapon system to engage an incoming missile must be made 
very rapidly. However, the detection of a surface shin at 2 


range of several hundred miles may not require a time 


Critical decision. 


Be CONTRIBUTIONS TO CORRECTNESS OF RESPONSE 

If the command and control network and the individual 
systems are to be evaluated based upon the response to & 
SEI mMmulws, it iis necessary to tdentify the contributing 
factors in arriving at the response. This will allow foe 
analysis of where corrective measures should Be applied to 
the network in order to improve the respons? valué of 
timeliness. The first area to be examined is the set of 
Pact ormS srintiuencing the correctness of the response. AS 
was stated previously, the response of the network is the 
result of the series of cesponses made by individual 


systems. Mreretfore, it is suffieient at this point to 
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examine the factors contributing to the response from a 
single system. 
:.  AWScwr a f erception 

The response to the stimulus is obviously based 
hHporm Ss perceptron of the nature of the stimulus, or 
‘environment in this case. Previously, it was stated that 


thea system does not see the environment as it really 


Craw S tes. Instead, it only sees a subset of the 
CyWarmpcotCeGri@tics, and mey not see these characteristics 
aceuratély. In orcder to property identify the stimulus, 


the system's perception of the environment must include all 


Stieecrme@e snGhatact@e@ristics of the environment that influence 


the response. tt is also equally important for these 
characteristics to be perceived accurately. hey One “oct 
tnese two conditions is not met, it could be the result of 


G@pecmerea Geficirency in the system's sensors, or it could be 
the result of inaccurate data forwarded by another system. 
Note taat one consequence of the latter case is that a 
system could provide accurate responses in one network, but 
mieemeectaily in another network due to interactions with 
other systems. Thus, no system should be ignored in the 
analysis of a network simply because it performs well in 
other networks. 
q ; Availabilit of Su ertin Information 
Given that the system obtains a sufficiently 


Beecurate perception of the environment, it must use the 


29 





local database to support the decision algorithn. The 
local database may or may not contain the neaded data, and 
as with sensor data, it may or may niet be acerrate if it is 
present. Inaccurate information in the database can result 
from storing inaccurate sensor inputs or rt can result from 
improper processing of previous ingputs. 
Si Decision Algorithm 

The sensor and database data is acted upon by the 

decision algorithm in the system. Obviously, errors in 


this algorithm will introduce errors in the response. 


Go CONTRIBUTIONS TO TIMELINESS OF WYESPIONSE 

The titmeliness of the response ocf 2 system is the sum 
of two factors, the time for the svstem to detect the 
occurrence of the stimulus, and the tine required for the 
System to determine the response arfrter the stimulus has 
been detected. An analysis of Gieoce  CLagtors wsualldy 
includes a complex analysis of the communications delays in 
the network. But if the edges in the model are treated as 
instantaneous transfers of data, the tommunications delay 
analysis becomes a special case af the general systen 
analysis, since the delays are introduced By either a 
communications system represented by a node in the model, 
or by the decision algorithm in the environment, which 1s 


modeled as a system. 
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i. Rauting through Network 


The time for the system to detect the stimulus can 
be generated by either or both of two factors. TR emt i rst 
Factor is the time required for other systems in the 
network to process and forward their results. The second 
factor ts the time required for the system sensors to 
integrate the data once it is present at the sensor. OT 
example, a normal search radar will average half of the 
rotation period in order to detect a target after it enters 
mien Coveresge of the radar. Before, it was mentioned that a 
stimulus ts tn the form of a set of characteristics of the 
environment. The individual elements of this set do not 
always come from the same sensor or source, and thus could 
easily be subjected to ditterent time delays in arriving at 
the system. Since all of the elements are necessary to the 
decision algorithm, the last of the elements to become 
available to the system determines the delay in detecting 
the stimulus. 

Le Time to Determine Response 

Within the system, the time required to arrive at a 
decision by the decision algorithm and to communicate this 
decision can be divided into three components. 

a. Input Queue 

The inputs from the sensors are queued in the 
system waiting for the decision algorithm to act upon then. 


This can easily be seen in a typical manual command post as 
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PaerErnNC@ming Message traffic piles up waiting for action 
officers to Become available. Each system will have a 
ear Wetent queue policy, ranging from a simple first in 
first out processing to complex prioritization schemes. 
D.. Processing Time 
Each decision requires a finite amount of time 
for processing bv the decision algorithn. Continuing the 
example of the command post, this represents the time 
during whien the action officer ts acting on the message 
C., Output Queue 
Barta .y,) «ne decision tvs subjected to another 
queue upon being released from the decision algorithm for 
communication In tha example, this is represented by the 
time required fer the response message to be formatted and 
transmittad It also includes the time spent waiting for 
other messages to be released ahead of the message of 


interest. 
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Vv: USING THE MODEL AS A BASIS FCR SIMULATION 


This section shows how the previously presented model 
can Be used as a basis for the simulation of a network of 
command and control systems. The discussion wiil center 
upon the use of computer technology to parovide the basis of 


the simulation. 


AD. SINGLE SYSTEM SIMULATION 

Recall the single system model of command ang eontrol 
Meets WAS DPresentad in Figure 2. Wsimg “his wmode l, a 
Simulation of the system can be constructed with a logical 
Serge tre as prasented tn Figure 6. Tt is tmp sraeant to 
Mote that this structure is designed to allow thea analyst 
to view the individual system from a stimulus anc ‘fcesponse 
point of view. There is no desire at this ievel te axamine 
the internal operation of the system. A complete analysis 
of the system would require additional tools to egxemine the 
internal dynamics of the system. The primary purndose of 
the structure in Figure 3 is as a Buiiding Block to be used 
in simulating networks of systems. 

There are three components in the simulation. The 
Simulation of the environment will be discussed later, as 
will the interface process. The model and the simulation 


structure were developed with computer simulation in mind, 
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Environment Interface System 


Simulation Process Simulation 





FIGURE 5S. Single System Simulation 


but it itis not necessary for the simulation of the system to 
be a computer simulation. This is true even when the other 
two components are implemented on a computer. AS presented 
in Section [12, a Single individual can be regarded 35 a 
command and control system. In this case, tt would be much 
Meme cy and probably much more realistic, to present 
“ilvetoul Masts. oT from the interface process directly to an 
individual! for evaluation and to relay the responses back 
to the interface process. The only "memetriction thet really 
applies to the system simulation is that it must be 
designed to accept the data provided by the interface 


process, and must provide output data in the format 
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emppea cteqd Cy tne intesteece process. Grtn @°r etiam taics 
restriction, the simulation can be implemented by any 
available technique, ta inelude mathematical models, 


Somputer simulation, mantrad scimulators, or an actual 


system. 


B.. NETWORK SIMULATION 

The extension of the single system simulation to the 
simulation of a network sf systems will be presented by 
e@ekamining an example case. Tarts example will then be 
extended to the general case. Consider a network of three 


command and control systems such as that shown in Figure 4. 


Sensor 1] link 1 external 

Sensor 1 systems 
| System 

Sensor 2 Z ia : 


Sensor 4! 





FIGURE 6. An Example Network 
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Using the model in Figure 4, and the general structures of 
Figure 3, we can simulate the network with the Log: sil 
meructurce given in Figure 7. Eech of the Siimuiiat toms fae 


systems A, B, and C is as specified above. Note that the 


System AA 


Simulation 


eer ae er ee Ce et ee SO 


Environment Interface System B 


Simulation 


Simulation Process 





System C | 
Simulation 





FIGURE 7. Simulation of Network 


! 
! 
| 
| 
| 
: 
| 
| 
| 
| 
| 
| 
— 
four weapons systems do not appear as part of the command 
gememcOTMtro!l network in the simulation. As discussed 
earlier, these components are part of the environment 
Simulation. Thus, it becomes evident that the manner in 


which the environment is simulated will have a major impact 


Swecuecmvalidity of the éntire simulation. 
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om SIMULATION OF THE ENVIRONMENT 
: Iitems to be Sim ate 

What elements of the environment should be 
Simulated in this example, and how should the simulation be 
er sus tured? As stated above, each of the weapons systems 
must Be simulated. It is also necessary to simulate the 
wee rons Gf opposing units and other friendly units. It may 
aiso be necessary to simulate such environmental factors as 
weather, time of day, and terrain if these factors 
influence the simulation of other elements such as unit 
movewent or sensor performance. 

Cne of the most difficult parts of the environment 
gimulatron will be in the handling of the system sensors 


for #@ach system. As mentioned tn previous sections, a 
Mr 6 Stac Simulation of the various parameters af the 
enviconm@nt is insufficient. Each sensor will have a view 
@rt eoniy a subset of this environment. tw waaqrtion, “two 
Sensors looking at the same subset of environmental 
Pacameters may still arrive at two different perceptions of 
the environment, since each sensor will not sense the 
parameters with the same accuracy. Different sensors will 
also assign different interpretations to the same parameter 
Values. Thus tt ts necessary for the environment 
Simulation to filter and modify the environment parameters 


before they are presented to the system simulations. Ties 


is especially true if the system is simulated 5y a person 
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or part of an actual command and control system. Leet hts 
case, the simulation of the system cannot bea used to modify 
the parameters. If, on the other hand, a system simulation 
is designed strictly for use in the network simulation, the 
parameter filtering can be accomplished either as part of 
the environment simulation, or as a task within the system 
Simulation. The former method provides more flexibility 
since many types of sensor technolsgical changes can be 
accommodated with no change in the system simulation. An 
example of such a change could be an improvement in the 
Greemae yy Of the location reported f€o0r a target. 

mmother component of the environment that must be 
Miomsiagered is the set of charatterigtieés of the seven 
eommunications links within the networ®P. Since these 
characteristics may be variable, and have a major impact on 
the overall performance of the network, they must be 
Bercoumted £or. Depending upon the level of examination, it 
is reasonable to consider them as @ither part of the output 
task within a system simulatien, or to represent the link 
as a separate simulation parametar in the environment. The 
latter appears toc be a more general approach. It allows 
Ditemeeiaminen, Characteristics to be modified to account for 
technological, environmental, or procedural change without 


having to modify the system simulation. 





Ls Simulation Methodology 


Recall that earlier it was stated that the 
environment could be regarded as a system for purposes ov 
modeling and analysis. When the proliferation of 
environmental parameters is examined, it appears to be more 
reasonable to consider the environment as a network o£ 
Interacting systems. Since a method of simulating a 
network of systems has already been presented to simulate a 
command and control network, it seems reasonable to see if 
this same methodology could be applied to the simulation of 
the environment. When the methodology is extended, it 
mestiimes=erim 2 LOgGical configuration like that in Figure 8 

Beeguce 8 revesis an interesting result of this 
aooroach . Tt no longer matters whether a given individual 
Simulation or task is part of the environment, or whether 


ier coupe: € Of the command and control network und®r 


St dmMrnation. This is a rather subtle, but extremely 
powerful result. It means that 1£ the structure presented 
can be implemented, then several apparently divergent 
problems can be solved economically as a group. Consider 


SeeateasGustemme r ying tCoudetermine thessvulnepabriity of a VU.&. 
command and control system to Soviet counter command and 
control measures. In this case, the V.S. system is the 
nmetwork under examination, and a network of Soviet systems 
is part of the environment. Now consider another analyst 


Wo is trying to find a vulnerability in the Soviet counter 
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FIGURE 8. Tasks for Example Network 





command and control measures. Now the Soviet network is 


the network under examination, and the U.S. systems are 


part of the environment. However, since the interface 


process doesn't need to distinguish between the network 
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Gmmecr Sx 2Mination and “he CWs ks that eomprise the 
environment, the same simulations could conceivabiy be used 
im Both instances if they provide the proper level of 


Simulation. 


D. THE INTERFACE PROCESS 

It should have been apparent from Figure 6 that the 
imterface process Can very easily have numerous connections 
BO 4a Muttitude of gimulation tasks. In tact), wae cy iunowt 
momoreeaougtput from a simulation task is conneczcied to the 
mncerface oroce ssw. As the huB of the enti vr dei mu lastion, 
Mere bmtertEace process is the prime determinant of the 
Sereda Characteristics of the simulation mmvyironment. 
bavytronment in this case,refers to the externai structure 
within which the simulation exists, as opposed to the 
Somm@and and control environment that is simulated as part 
Sere tne overall simulation. AaNemm@e  Ority ot “he remainder 
of this thesis will Be devoted to the necessary 
eitactacteristucs and functions of this process 

Le. Functions 

Figure 9%? shows one of many possible configurations 


MOG NemEGoueing of data within the interface process (OF 


the example of Figure 8. Even for this relatively small 
example, the routing of information is obviously a major 
function to be implemented by the intecface process. Note 
that there are two types of Links. There are one-to-one 


imemicsmewiuere the output of a single task ts routed to 
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FIGURE 9. Example Links Between Tasks 







another single task. There are also one-to-many links 
where the output of a single task goes to multiple 
G@escvimation tasks. There are also many-to-one and 


Many-to-many links, but these are logically equivalent to 





meeeoeOt  Ome—-to-one ot one-to-many links. Thus, the two 
types are sufficient. 

Recall that the gurpose of the simulation is to 
analyze a network of command and control systems with 
respect to a stimulus and response model as presented in 
Spection IV. Recali atiwso that all of the information 
necessary to accomplish this task is present at the inputs 
and outputs of the tasks comprising the simulation of the 
network. Thus, it is desirabie that the interface process 
Brovid@e away to capture the content of the logical 
binkages. 

Obviously, it is not desirable to capture data 
PeeeoeSel mG 2eCross each logical link. Also, the linkages 
associated with a teask cre dependent upon the specific 
instance of its use tin a simulation. Tt is necessary to 
establish and to modify the operation of the interface in a 
Manner that ts independent of the simulation tasks that are 
Pemmg interfaced. This aeans that the interface process 
must implement an interface control mechanism for use vy 
the experiment controller. 

a Im ementation 

The following implementation is presented as 2 
method for accomplishing the three fundamental interface 
Beoogrmse =tasks of logical linkage, data capture, and 
Somer O 1. At this point the assumption is made that the 


interface process is implemented on &@ computer system, as 
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Meeeomeeach Of tne simulation tasks. A methodology will ie 
given ina later section for the case where the simulation 
tasks are not computer based. 

Let the interface process be implemented 35 a 
process at the utility program or supervisor level in tke 
computer system. This allows it to be accessible to ali 
other tasks, and to have access to the computer system's 
mee structure. The need for the £/0 structure access wi!) 
become obvious later in the thesis. 

Whenever a task begins execution, it accesses the 
interface process and passes a logical identification {9 
the interface process. The =metWod ef accessing “the 
interface process 15 obviously an item which is very 
dependent upon the computer system utilized. LE “1S Crus 1 
Meat the identification Be unique. Eor instance , St an ar: 
defense battalion was being simulated, copies of the same 
megeeecould bemused for each of the ££ Ping batt er mes. 
However, each would require a s@parate Logical 
identification so that the batteries could be distinguished 
by the control interface. 

Whenever a task “opens"™ a communications {ink with 
the interface process, this Link ts assigned a logical 
name. For output links, the assigned name is the name of 
an address list with which the link should be associated. 
There is no requirement for a given address list to be 


Omemawee to 2 Particular output channel. Input links are 


44 





mamed with a name that is unique within the task. Weneis 
Rame is concatenated with the task identifier to obtain a 
umique channel name. One of the tasks to be accomplished 
Sy the control function will be the mapping of address 
lists to the channel names. To do so, the control function 
wiil maintain a list of one or more channel names to be 
uséd for each logical address. Whenever data is received 
from a task By the interface process, the data is sent to 
each input channel whose name is on the address list 
ae~sociated with the output channel. This allows both 
one-to-one and one-to-many Links to be implemented by the 
Same mechanism. Tt also allows data which is generated, 
Bac not needed in the specific simulation being considered 
to be discarded. Tleivis 15 accomolished by putting no 
Mere cies in the address list. The interface process must 
Rilow a given channel name to appear in multiple address 
me sts. This ensures that the logical many-to-one and 
mMany-tdi-many Links can Be implemented. 


Returning to the example of Figure 9, consider the 


tour weapon unit tasks. The tasks can be initiated with 
Mie Lleogitreal names unit_1l, unit_zZ@, unit_3, and unit_4 it 


each of the units is simulated by the same program, the 
input channels will be assigned common logical Link names. 
Let these names be weather, comm, and location for the 
inputs from the weather, link, and friendly forces tasks, 


respectively. The logical link names are concatenated with 
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the task logical names tc produce {12 unique channel names; 


unit wil.weather, unit t.comm, unit olt.location, ..., and 
morrt 8". Pocation. The cutgut from eech weapon unit task can 
be assigned to address list damage. Sinee the names are 


not unique, the output from ali four tasks is merged into a 
Single data stream. Tf a separation had been desired, the 
tasks themselves would have to concatenate the task name, 
Since only input nmames are antomatically concatenated. The 
Matertace process knows that address List damage contains 
the channel names opposing.damage and friendly.damage. 
These are the input channels for the two forces tasks. The 
Manner in which the interface process krows the members of 
the address list wiil be discussed later. 

Gre address list scheme wiii also solve the data 
capture problem. All that is necessary to capture the data 
from a given link is to initiate a task that will operate 
mie Of record, the data for a given iin, and then to open 
meer mnpuwt Channel from the interTace process. Adding the 
Channel name for the data capture task to the appropriate 
address lists will complete the ftunstion By capturing the 
data regardless of changes in the tasks associated with the 
Te 9 am Continuing with the ezample abdove, adda log task t9 
the simulation with an input channel log.damage which is 
used to receive damage data for recording. Simply adding 
log.damage to the address list damage will allow the data 


Comme Goomed 2at log in addition to the forces tCasks. 
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The control function can be implemented in much the 
Same manner. Design the control function as a coilection 
Bee cooperating tasks. Figure 10 is a possible 


configuration for the interface process for some simulation 
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FIGURE 18. Interface Process Configuration | 


and host equipment. An individual task can be considered 
as being of one of two types. The first type ts a task 
which must be present and logically connected to other 
tasks when the interface process Begins execution. These 
tasks would include tasks which perform address list 
maintenance, tasks which physically route the information 
between input and output channels, tasks for Wire i-a . ing 


other tasks, and tasks for opening channels. These tasks 
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wWeli Keceatter Be called primary control tasks, or simply 
Ger lary. tages. At other contro! tusks are Secondary 
Cooemet £0... t aterks. These tasks include the tasks which 
interface the test controller to the interface process. 
(The test controller could be a human operator, a team of 
operators, or another computer process. ) Assume that the 
linkages between primary faces Sulriomcmne d and 4 re 
estadblisheaq at task creation time as in a conventional 
process. elim Linkages among the secondary control tasks 
and Between the primary and secondary tasks can be 
Mmplemented using the interface process itself. Let the 
input and output channels assocrated with each primary task 
be named by a@ fiued convention, and place each of the input 
channei names on at least one address list which is also 
mamed by convention. Each channel of each primary task 1s 
now accassibdBie te any process that can access the interface 
process. Tihts tans that tne exact contiguration of the 
PwOmiereseo cn mersuMne tion iS determined By the selectton of 
mec Onmadgry Control tasks, and their linkage to the primary 
tasks Tats, it is easy Co virtualize the control function 
Mmommecuscumeitd:ividual requtrrements and to add tasks as 
necessary to meet unique control problems for a given test 
environment. 
oe Task Simitarity 
Note that as far as the interface process is 


Gomcernmed, the tasks that comprise the sitmulation, the 
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PewoeS Ciat implement the data eapture funetiscn, and the 
secondary control functtons aii apnear tne same. Tia Ss 


means that tn subsequent discussion of task flinrages, it is 


only necessary to discuss four cases; 


a: primary task to primary tasx, 

b. Primary task to secondary task, 

C. secondary task to primary task, and 
a secondary task to secondary task 


Since the latter three casesS are implemented 


identically via the interface process, there are really 


ce 


Omiv twO cases to consider; primary task S QErmacty task, 
mrad. a2il others. Hereafter, the term secendary task will be 


/Mseeag to e€oltllectively refer te all tasks other “Ran primary 


tasks, regardless of functtonal purpose. 
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VI. Meio. OF ATP ESaRLBUTED SIMULATION 





In this section, the methodology of Section V will be 
extended to the distributed simulation of networks of 


command and control systems. 


A. WHY DISTRIBUTED SIMULATION? 


The simulation methodology presented in Section V is a 


Logical network of tasks. This network could be 
implemented in a single computer, if the computer could 
support all of the processing required. An examination of 


the size and processing requirements of even a modest 
Single system simulation leads to the inevitable conclusion 
that the representation of any significant level of detail 
In the systems comprising a network will result in an 
enormous processing load. The time needed to accomplish 4a 
Simulation on a single computer makes a strong case for 
uSing multiple computers in a distributed processing 
arrangement. As used here, distributed processing refers 
to any collection of two or more processors processing 
components of the same problen. This ineludées colocated 
computers operating on a multiprocessor Bus or Local area 
metwork and also includes geographically dispersed systems 
connected by a Long haul communications network. Lt also 


Sov Gor ther nybDrcid systems rcesurltting from networking 
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meegraphi:ecaeltly dispersed Sroae@ssing nodes. erie wel Wer vad wa IT 
Perrorcee SS ING nodes can S@ tindividuai computers, local 
networks or a multiprocessor configuration. 

Although the purely technica! issues argue for a 


distributed arrangement, there are other strong reasons for 


a network. Recall the problems discussed briefly in 
src cion i. One of the problems was ‘the amount of time that 
it takes for the development sf a tast system. jqy 


Meieose tr iDieewe d System, 2an GEganization™Wirth a functional 
requirement closely related to one aiready accommodated 
within the network oniy needs to develop minimal 
Meoditficeawtions, and a capability to mceccess the network, in 
Seaver tGO Obtain an initial Simul@tion capability. The 
technical aspects of the approach are presented in this 
sectitron and in Secttitons VII and Vili The management 
aspects are presented in Section [&%. 

The second problem area concerned the retention of 
[emGltmicatl expertise by the staftt menbers of the 
Suganhisac tons conducting the simulations. Thrs problem is 
usually manifested in the ares of scenario development. 
PERE QM@—UmeCun re s@arch and stattina tnrat must go into a 
Stesesa CeOmrrm Grde@r to make tt acceptable to all of the 
parties which are reviewing it, very few scenarios are ever 
developed by any organization. These are usually just 


Vaeariations of acsingl@mwmastear scenario. The use of a 


distributed stmulation with all of these organizations 
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Patecrcunma ting would allow the Sharing of both the data 
Bases that define the scenario environment, and the 
processes which control and distribute the scenarios. 

A distributed network also provides a Significant 
capability to organizations which normally would have no 
Simulation capability. Analysis organizations within the 
meee vercesSs tyoically have insufficient computer assets for 
command and control network simulation. However, they 
usually have highly refined statistical analysis tools. By 
adding these organizations to a network, they gain access 
to simulations, and the organizations which are developing 
the simulations can concentrate on the simulations, knowing 
that the analysis tools have Been debugged and havea been 


made available for use. 


B LOCATION INDEPENDENCE 
The key to making a distriButed network feasible is tg 


make the logical connectivity of a task independent of it's 


Beorysiteat location. The solution ts represented in Figures 
ay a The primary control tasks are augmented and are 
replicated in each of the network processors. Any task 1/0 


that is passed to the interface process in any processor is 
passed to the proper tasks, in whichever processors they 
May reside. 

Let the primary tasks in each processor have functional 


control over the communications between the processor and 
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FIGURE 12. A Distributed Architecture 





other processors. Note that it is not necessary for the 
Sepermmeacry tamecks tw directly control all of the links. The 
Gessua protocol! and line handling could Be implemented By 
Ge operating »yst@m utility or network communications 
package. Tt i685 @Ogsential though, that none of the 
secondary tasks has direct access to the communications 
eis . 

At least three methods are now possible for routing [I/O 
COmette oer oper task. Wrrememetihrodgeeactually wtilizsed is a 
Matter of a tradeoff between network complexity and 


fee ro ikity. 
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Mime"iliirst method is the least compiex, but 2zlso the 
least flexible. When a task is initiated, the Logical 
address used to identify it within address iisis will 
Srollt ain a processor idantifier. Tus ;, We pr Mier y 
interface tasks always know the identity of the déestinazion 
processors. Data Vemerout ed toms ch ot vetive  t ar get 
processors, where it 1s passed te the primary intertace 
Marek s fOr routing to the proper tasks Cire s Oo UTese , 
efficrency of communications dictates that the transmission 
to multiple tasks at the same processor would only result 
in one data transmission, with multiple copies being 
generated at the receiving processor 

In the second methodology, every I/O transaction is 
Broadcast to all other processors, addressed ta tne address 
Mmrst name. The primary tasks in each processor aneck the 
Specified address list for local tasks and pass the data to 
Maro kK S 2S appropriate. Many Docai networks and 
Pmetee tC DEOcCessor Buses use a2 Broadeasi metnod for 
@istributing data on a fring or star network. When this 1s 
the case, this methodology is a very simpia end flexible 
alternative. Of course, this method suffers from obvious 
deficiencies in geographically distributed networks with 
limited Bandwidth between processors. 

The third approach is for each processor to keep a copy 
of all address Lists being used By local tasks. A special 


address list, named by convention, would broadcast to all 
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processors as itn method two above. One use of this special 
address list would be for the dissemination of changes to 
normal address lists. A secondary task, named by 


convention, would maintain a master copy of all address 


Listes’. When the primary tasks in a given processor needed 
to initiate a new address list, they would obtain the 
initia! list from the secondary task. The lists wouid 


identify Logical names and processors for each task. 
Although conceptually the most complex, this is the most 
Prexzible approach. It allows tasks to migrate among the 
processors from execution to execution of the simulation, 
or even during a given execution. At the same time, it 
Minimizes the problem of channel bandwidth by keeping local 
subsets of the routing information. Pn stive- (event. of ‘2 
farlure that removes the master copy of all address lists 
from the network, the [List can be reconstructed By merging 
all of the local subsets which remain tn the Surviving 
portion of the network. 

Combinations of the above approaches are also feasible. 
For instance, either method one or method three could be 
used to route data between two local networks, and then 
method two could be used within each local network. 

Note that only the primary tasks within the interface 
Process need to be replicated within each processor. Ail 
other tasks are needed only once within the network, and 


may logically reside anywhere. 





c. BEYOND A CLOSED SYSTEM 

All of the tasks dGiseussed so far have been assumed to 
have the ability to communicate with the interface process. 
However, there are simulation capabilities which must be 
Srommesr Gee red fOr in@®rporation in any serious effort to 
Simulate a command and control network, but which cannot 
Sommunmreacte directly witehh the interface process. Two 
examples will be qiven. 

Over the years, each sft the services has developed a 
large inventory of manned simulators. These systems 
provide excellent capabilities for simulating Sotn command 
and controti systems and weapons systems. However, these 
payee ems Generaliv reside on dedicated hardware, often 
without any operating system primitives beyond a simple 
Monitor and Soeotstras iozder. Lt wold be Gitt:recult, and 
PeeQuSiaeosl Veslmprudent, to madity them to tneorporate the 
interface process?s Orasented A@Grein. 


Fortunately most of these systems were designed for, or 


have been modified for, stimulation and monitoring by 
external computer systems The term stimulation is often 
Soni tiseed with themeterm @itmulation. A system is simulated 


by a process which models the actions produced in the 
Simulated system. A system is stimulated by providing an 
mmout (Cor possibly a Lack of an input) which causes the 
system to react in some manner, predictably or otherwise. 


mings ec Computer interfaces provide the key to utilizing 
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these systems in the simulation network. Are t-2 Gi Xeeen TV (bie 
created that maps the simulator interface to tha interface 


required by the interface process, as shown in Figure i2. 


This task is executed in a computer colocated with the 
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1 


Simulator, and results in the simulator Being addressed is 
if it was a single task, peopie and all. 

The second example is when it is desired to monitor the 
exact exchange of data which 185 occurring between two 
tactical systems. Meet it > Cdasm, tie tarcabpeal interface 
must be as close to the tactical employment as possible. 
Use of the interface process would disturb the timing and 


handshaking characteristics of the interface and result in 
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tnvyaltidation of the entire test. HMowever, it is desired to 
collect the data and analyze it using network assets. The 
soiution here is similar to that above, and is shown in 


eitguce 13. The data is captured at the tactical interface 
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FIGURE 13. Capturing Tactical Data Streams 





by any suitable means and is passed to a computer task that 
meets the interface process criteria. The data 15 now 
avallable throughout the network. 

This basic methodology can be used for many tasks which 
atri@® not directiy suitable for the interface process, 
including simulations which are not computer based. 
Command posts are often simulated simply By a staff of 


people and some rudimentary communications for receiving 
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strmuli and relaying decisions. Pina COMpa@ter terminal is 
termed for the communications, possibly staffed by a test 
Sontrolher, then the stimult can be r@leased by a task in 
the network simulation, and the rasults feaed back into the 
network. All that is needed is a suitable interface task 
connecting the interface process to the terminai at the 


command post simulation. 





Veil. CHARACTERISTICS OF SIMULATIONS 


There are many existing simulations which could be 
adapted to the methodology presented in the previous 
sections. However, the Basic characteristics of these 
Simulations are dissimilar. These dissimilarities arise as 
mumreeotr 1 t Of both the characteristics of the item Being 
Simulated, and as a result of the individual preferences of 
the stmulation designer. These dissimilarities can be 
expected to continue in any tasks which might be develoned 
specifically for the presented methodology. Two of the 
Mideaacwemrstics are significant to the simulation model. 
These are the time line basis of the Simulation task, and 
the conventions that are used to pass information between 
the various tasks. Ties@e chatract@pwstics of simulations, 
and theic impact on the simulation model, will be examined 


in this section. 


A. TIME LINE CONSIDERATIONS 
Simulations generally are time line classified inte one 
of two categories, time step or event step. 
Aor Times S bap Simulations 
In a time step simulation, the task 1S given the 
state of the simulated phenomenon at a specific point in 


time. The task then calculates the state at a specific 
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Etmom*  intercval later in time. As an example, consider the 


eyamwmiation of the tmrovement of an aircraft. The task would 
Peatmm the aircraft's position, heading, rate of 
Seerpmo/desgce@eut, and velocity at some initial time, t 

Based upen some time increment Cae the task would compute 
the aireraft position at time ie During the next 
iteration, the position would be computed at time ee ane 
ama SO €orth. Pe Cai liy > sin this. tyne of Simulation, 


changes in heading, rate of climb/descent, or velocity can 


only be made at time er for some nonnegative integer 


q! 
Z Evemt Step Simylbetion 

feet e that if .changes in heading, rate of 
Simo; descent, or velocity occur infrequently, a period of 
Memear airerazrt motion is ealiculated as an accumulation of 
short segments cf motion. Pot S@ivew ti meao o£ ‘thie ~f irs t 
@ireraft maneuver is known to be oi Ot the location of 
Miia treres Ft when tnitiating this maneuver can be 
Seaeecuraeed directly from time - in one step by using 
Et z Godt... This requires considerably less work. This is 
the :desa oGehind the event step simulation approach. A list 
of avents (the maneuver in this example), and their time of 
Seeurrenee iS Maintained. The state of the simulated 
pmemome@enmon is cGaleulated for thw time of the negt 


chronological event, based upon the state at the last event 


time. The prime disadvantage of this approach is that the 
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time of occurrence of all events must be known tn i29072nce 
Memes can often be very complicated to commute. Eso fr 
example, consider an early warning aircratt operating in an 
environment that includes several other aircraft: and some 
Opposing electronic warfare assets. aS the various 


atreraft maneuver, when will aircraft be detectad ocr lost 


by the early warning radar? 


B. [NFORMATION PASSING CONVENTIONS 

There is an obvious need for the varicus t23%¢s within a 
Simulation to pass itnformation among themszvzives The 
Peeoope bE method for accomplishing this function is fiot so 
obvious. One of two methods is generally tesed. These 
methods are message passing and the use ot a common data 
base. 

ee Message Passing 

One approach to data passing is to transfer items 

@r data directly from one task to another. Z2is can be 
implemented in a number of ways depending upon the specific 
equipment suite. One common method is the nassing of 
Seaeh ame Cm@rrs in a subroutine call. Amotme tr is the 
establishment of a queue where records are deposited by one 
task, and retrieved by another. The essence of the process 
is that task 1 calculates some element of data and sends it 
Ipjomeeetedus kee) Gitcectily across some logical ehannel of 


communication. This approach is simple, But there are some 
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very rigid assumptions that must be met in order to avoid 
disaster. First, task 2 must be able to process the 
received data at a greater rate than it is produced by task 
es In some cases this may have to be accommodated by 
allowing task 2 to simply dump or ignore messages when 
overloaded. Secondly, task 1 must generate the data in the 
order in which it is needed by task 2. When the order in 
which task 2 requires data is not fixed, nor predictable by 
task 1, it becomes necessary to establish some sort of 
handshaking so that task 2 can pass it's requirements for 
data to task 1. This is usually implemented by a message 


Passing channel from task 2 to task 1. 


Ze. Common Data Bases 


Consider the following tasks. Task 1 calculates 
miuem current position™of a ship. Task 2 calculates helm 
commands for the same ship. Dt bs, Obvious that task 4 


Mmectrres the current Location, Reading, and speed of the 
Sto im order to caleulate a new location. Task 2 needs 
the location, heading, speed, and other data that possibly 
includes mission orders and the location of other vessels, 
mrneeorder to calculate a mWew heading or speed. Ln tive 
common data base approach to information passing, a data 
base would be established that included at least the 
location, heading, and speed fields. Task 1 and task 2 
would both have access to this data Base. Whenever task 1 


Galculates a new location, it simply updates the location 











freid of the data base. When task 2 needs a Location for 
Sine Ship, it *simply caads the vaiue in the location field. 
New helm commands resuit in a chanyea to either the heading 
See tne speed fields, and are immediately available to task 
Le: The two tasks can thus function asynchronously. The 
approach is not withoywt problems however. Whenever task 2 
meeds a Location value, it must query the data base because 
the value may have been updated. This doesn't cause a 
problem with two tasks and only 2 data fields. But as the 
mumber of tasks with common data fields increases and the 
size of the common data bases grows. it may de necessary to 
utilize secondary storage for taase data bases. Depending 
upon the equipment and operating system used, these 
Mumerous references to the dats bDasues can be Severely 
limited by the bandwidth of the channels available for 
access to the data bases. Configuratton management can 
also be a problem. Whenever the structure of a data base 
Memmeoaititred, the Location of dated needed by a given task is 
modified. There @~rée se@evecal methods for minimizing this 
impact. mine most GOpulsar aposcach th recent yelars is tne 
MicmemmGcuretets KS, GfKrtean calied tntiorcmation hiding modules, 
which accept logical data requests from the task and 
Scovidewmtme Logical to physical mapping and retrieve the 
desired data. Although simple in theory, this approach 


Simply moves the point at which the modification must be 
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made, and may Rave an impact on the bandwidth of the access 


channel. 


Si. HYBRID CONFIGURATIONS 

As shown above, each of the time Line and intormation 
Passing methods has advantages and disadvantages, and none 
is best suited to all Simulation tasks that are to be 
performed. Therefore, the network simulation methocology 
must accommodate tasks based upon each of these approaches 
if rt is to be useful. 

A important question is whether or not there is a 
legitimate need to miz both time line methods, or both 


information passing methods in a single simulation of a 


network. Consider the previous example of the early 
WatTmMing aircraft. Lt would appear that 2 time step 
Simulation is best for the movement of the aircraft. Radar 


Preece om cam woe computed esch time xsnterval and the 
problem of predicting the time of detection is avoided. In 
many conceivabla simulations, the movement of the Rostiiea 
aireraft would be predetermined and the maneuvers stored in 
auyasGé@Matio. The task which reads the scenario and sends 
the maneuvers to the time step aircraft motion task 185 most 
easily implemented as an event step task. Thus, the two 
time line methods might be ancountered in a single network 


Simulation. 





Consicer the simulation of two command and control 
Syosset fms Which are tracking a number of aircraft. Punt nes 
assume that the best method for the passing of location to 
the system simulations is via a2 Common data base in this 
case. howe consider the simulation of a communication 
channei that carries track update messages between the two 
systems. AN important aspect of this channel is the order 
in whien tha information is passed, since this affects the 
processing Dy the receiving system. Thus, the message 
Passing methodology appears to be ideal for this case. In 
Senaiuston, Seth information passing methodologies might be 


present ina single network simulation. 


as. MAKING INTERFACES COMPATIBLE 

wee ee tt ON Vi, itt was stated that tndividual tasks 
could be developed independently, and that they could 
resida within different test system elements. These ideas 
will form the basis for examining the issues associated 
MEEwGetrawe. interfacing of tasks. The interfaces will be 
SemGm@eiedecotimer i 2EG tinto general types based upon the 
Charactweeristitcs oresented in this section. 

Ail interfaces examined in this section will be assumed 
to be a one to one, single direction interface used to 
MEdgmstermimcOtmation from task 1 to task 2, as shown tin 
Per quer ©. 814 . Note that the interface process is not shown, 


and it will simply be assumed for the remainder of this 
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PlOWte ioe Tash eimeeiny acum 
section. When two tasks are selected for use tin a network 
Simulation, they must satisfy a set of assumations before 
an interface can be established. These assumptions are 
independent of whether or not the tasks ara selected "off 
the shelf", or are developed for the simulation. 

The set of inputs required by task 2 must be a subset 
Of tCives outputs from task 1. Note that the seis do not have 
COs bremmicae it tical... When the output of Caste contains, but 
SL Gecedas the input tcequirements for task 2, tt is 3&2 simple 
matter to filter the output of task 1, as shown in Figure 


rs. When the output of task 1 does not contain all of the 


Pere required by task 2, the input deficiencies can be 
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FIGURE 15. Task Interface Filtering 


satisfied by one or more additional tasks as Shown in 
Pagure 16. However, for the remainder of the section, this 
cease will be assumed to have Been decomposed into two or 
more separate logical inputs to task 2. 

The data input requirements of task 2 must be expressed 
in the same terms as the data output from task 1. As an 
example where this is not the case, task { might provide an 
Sern ceteomea dt tl tude min meters, while task 2 expects to 
receive the altitude in feet. If the first assumption has 
been satisfied, this assumption can usually be satisfied by 
converting the improper data items to the desired terms, as 


Shown in Figure 17. 
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FIGURE 


The ramainindg assumptions arise as a result of the 
Sumgpeactenrrstics of the individual tdsks involved. The task 
characteristics will be examined separately for the time 
‘eerne@oueand infotMastion passing combinations. Tenet Sen Ss 
possible because the assumptions required are independent 
and do not result from mutual considerations. 

ioe Time Line Interfacing 

ae Time Step to Time Step 
When two time step tasks are interfaced, the 
time step of task 2 should be at least as great as that of 
task 1... Mmiuemot, tmersituation shown in Figure 18 can 


a tales © . Meee Gatitculations pertormed by task 2 are 
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miceceey. ask Interface ranslation 


accomplished using information which is not current The 
tdeail case ts when both tasks have the same starting time, 
and the same time step. No time is wasted computing 


unneeded time steps By task i, and task 2 always has the 


most current information. When task 2 has a greater time 
Deomotm@iamemntask Lt, it should Be much greater, or Zn integer 
Merc tigumem=of, the task 1 time step. This wilt ansure 


Mwereiwcemtimrogmation in the case of an tintéeger multiple, or 
Mmmrermatihom with insignificant aging itn the case of much 
greater time step. When the step in task 2 exceeds the 
step in task 1, the filter task on the channel must be made 


aware of the relationship Between the time steps. This ts 
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li end of task 1 intervals 
to Time Step Interface 


necessary so that the unwanted time steps can be extracted 
from the task it output, while the current update is passed 
to task 2. 
be Time Step to Event Step 

When a time step task passes data to an event 
Geese tcaake, the tCranslation task on the Link must convert 
the output of task 1 into an event to be executed at a 
soeerfied time. Tio Se aneeoe saereomp bished: in “2a couple of 
manners. Mivewwrrrst 1S to reat each owtput from task 1 as 
an event to be executed at the end of the current time 
step. This essentially forces the event step task into the 


time step mode. This Loses the efficiency that event step 
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Mees Gain £froOm avoiding multipie identical oqamlculations 
Eat sum to a result directiy obtainable. The other 
approach is for the translation task to monitor successive 
outputs from task 1 and to oniy generate an event when 
there is a change in the data. In any case, this type of 
meee rtace should be examined very carefully to avoid 
introducing side effects into the simulation. 
(ales Event Step to Evant Step 

There are no reat concerns when interfacing 
event step tasks to event step tasks. This assumes, of 
Moiese, that tne selection ot the tasks is logically 
consistent with the simulation objective. The integration 
of several independently developed erent step tasks is very 
wot icult . This is because the essientially asynchronous 
Manner in which the events are generated and executed makes 
euegesref fects and logical ineonstistencies vary difficult to 
oredict or resolve. 

d. Event Step to TVYime Step 

mis Case iseigime tae time stien to timestep 
[reeertace with a2 variabie time step for task !. As such, 
it its susceptible to the data aqurrency problems when the 
Seeep times are not matched. Sincessthis mismatch is a 
MoeamomeMcmcOMmGlutton, itt can be frustrating to detect and 
SO he 2c t. This type of interface is only recommended in one 
Glrcumstance. This is when task 1 only affects data ttems 


which are discrete in time, and which cannot vary without 
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teasee 1 producing a new output. As am example, the location 


of a2 ship is a parameter which varies continuously in time. 


Pweet tok guegemerates a location, and task 2 uses it, then 
mer @ iS a2 problem of task 2 not Raving current input 
values. However, the heading of the ship is usually 


treated as an instantaneously changing value, and 1s 
Grscrete in time. If task 1 generates a heading, task 2 
can continue to use the same most recently received heading 
for several time steps without creating a problem. This 
assumes that task 1 will be executed whenever the Reading 
changes. It may be necessary for the translation task to 
remember the most recent data from task 1 and repeat it for 
each time step of task 2. 
es Tasks Without Time Line 

some tasks have no time line. An example might 
Be a task which given a missile type, a target ship class, 
and an impact aspect computes battle damage. These types 
of tasks are best thought of as subtasks within one cr mere 
tasks. eae they execute immediately and post results 
immediately, they generally present no problems other than 
the information passing problems discussed below. 

a Information Passing Interfacing 
a: Message to Message 
The interface process makes the interfacing of 


two tasks utilizing messages to pass information very easy. 


The interface between a task and the interface process 15 
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essenrntislly ccomp-.ished by message passing. Teas; aa 
message passing scneme is already present in each element 
of the simulation network. The only problems arise when 
task 1 expects to send messages directly to task 2, but 
task 2 expects to retrieve messages from a queue which 
buffers inputs. im this case, a task should be inserted 
me OQ ne logictl channel in order to accept the @essages 
from task 1, and to quewe: them for task 2. 

De, Message to Data Base 

The mestage passing task to common data base 

Bask ts also very simple. Task 1 passes the information 
Mla message to the translation task, which must be 
coresident with the data base. The transiattiton task 
inserts the data into tie data Base, where it ts available 
Momeuwoxk 2, 45 Wives in s@eetiron ec following 

ee Data Base to Data Base 


ProtLiems arise in the data Base to data base 


Mase tnterfEdce. Tf task 1 and task 2 are not coreasident, 
Sm ye one of thw tasks, if either, can Be coresident with 
the data base. The data base itself can be used as the 


filter task, Sur the translation task must still be 
Secpeea Utted £Orf . mire. SQ1lUE Lon fs to “Create a data base 
Secess Cask fOr @ach of thé tasks, as itn Figure 19. Ha Sie 1k 
Bassesswedata S5Sase Updates to aceess task 1, which is 
coresident with the data base, as messages. The access 


task performs any necessary translation and updates the 
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Access 
tease | 


micoemee ts. Data Base to Data Base Iatert sce 


data base. Task 2 requests desired data from access task 2 
via a message. The access task reads the data hase, 
translates the data, and sends the results vi2 meesajze tn 
ask 2. The portions of task 1 and task 2 whieh int@rttfact 
to the data base will have to be modified; But this 15 32 
problem that is inherent in using data base information 
passing. What is important is that the essential testure 
of the data base methodology, the data sequence 
independence between task 1 and task 2, has been preserved. 
oles Data Base to Message 
The most complicated interface to implement is 


when task 1 uses a common data base to pass information, 


yea 





and task 2 uses messages. Two cases exist. Veen e List. 


task 2 expects certain information at specified times, 


regardless of whether the data has changed since the iast 


message was received. THhie is typical of many tagke of a 


time step simulation. Figure 20 provides a general 


Access Translation 


Task Task 


pars 
Base 


FIGURE 2%. Data Base to Message 


Interface, case 1 





woproach . Task 1 updates the data base as described in 
Section c¢. A translation task coresident with the data 


base reads the data base at the required time, and sends a2 


message to task 2. In the second case, task 2 expects a 
Message only when a2 data item has changed. Pa this case. 
shown in Figure 21, the translation task must be notified 


Dem emmtask ft access task after a data item has been 
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FIGURE 21. Data Base to Message 
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modified. The translation task then collects the necessary 


data and sends 2 message t9 task 2. 
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WAG ge Ge 2 REA WORL CONSIDERATIONS 


There are several problems which will have to be 
addressed itn each simulation implemented using 2 
Geese ri buted simulation approach. Tire "purpose of Stents 
section is to discuss a few of the more difficuit of these 
common problem areas. iets limoo nh tant = to fea lace sth t 
these are problems which must ultimately be addressed ody 
the simulation designer, not by the network methodology. 
They are mentioned here primarily because they are commen 
to many of the simulations which logically might be solved 
Ween g the approach of a distributed simulation. Therefore, 
one or more of these problems will generally have to Se 
solved before the approach can be used. These prodlems area 
Eeieoogee tre luded for another reason. Experience would 
Mmratreate that there ts no Solution to any of the problems 
which has general acceptance among the tactical command and 
Somtrcol community. Tus) ere Wen he tn ren Wht ch “vies e 
problems are addressed will be one of thre Prine 
determinants in establishing how useful a task will be to 


other community members. 


A. SECURITY 
Computer security in general is an incomplete 


Gasecipline.. There are several theoretical approaches 
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PO Ge UG eircom security kernels to cryptographic systems. 


Uniottunately, there are not many applications of these 
theorias to real systems. Those systems which are 
implemented are implemented as one of two types. In a 


Singie level system, every task has access to everything, 
Becmwuse aliof the information is at or below the 
classification to which the least cleared user has access. 
In existing multilevel systems, information is allowed to 
Be miaqgrated from lower levels of protection to Higher 
levels, But the reverse is not true. 

Thezce have been attempts to avoid the security problems 
associsted with command and control simulations by creating 
sume st =cenario with “test only” unelassified information. 
Unfortunately, there are several problems to this approach. 
Seemem the connectivity af the various nodes within a 
Gamm@vt and control network is classified. Heding “the 
Gomme ctivity by using test only nétwork configurations 
Seaira @€ften invalidate the entire Simulation. When actual 
Paceebe dl inet @rfaces are itnvolved, the information conveyed 
Meerogs= the tnte@rftace may Fe perishable and of low 
SvlasGicication. Yet, almost all of the formats used for 
computer to computer interfaces, and many of the manual and 
computer assisted interfaces, are classified independent of 


Glassititecation of the content. 
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ARecepting that pm classified environment is 
unavoidable, is it possible to use an existing single or 
Multilevel approach to solve the probiem%? Thea answer is no 
in some cases. The task of some of the nodes in many 
command and control networks is thesteclassification or 
Gomrkt i Zation of Highly protected information for use by 
nodes with lower levels of access. A gocd example, without 
elaboration, is a direct support inteliigence facility. 
This requires the capability in the simulation of the 
meemtewor © f£Of a task to mak@® gortions of information 
Protected at some [evel available to tasks with an access 
Wemvwe l (that would nocmaliy preeciude access to the 
information. None of the current computer security systems 
wemounts for this typ@ of function. 

Mae omly approach with “any cus@tent Zgecaptavility, 
Maca ctuailily results in downgrading or sathtitization, ts 
the use of a manned simulator for the downgrading or 
Samat ization task. im the cisttibute?g simulation, the 
Manned simulator would be treated as a tioncompatible task 
and would be connected to the interface process by two or 
more distinct tasks, one at each Level of protection. 

Even this approach does not provide a solution 
™mmich is Gacceptable to wlil potential users. When the 
actual command and control system is employed in a tactical 


@envyrtomment, there is a risk that a Rhuman operator or 
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emmcomated process will improperly downgrade or san: th2é 
information and inadvertently compromise some portion of 
Pmremonriginal information. A major design and training 
Somcmrm im the real system is to maintain this risk at a 
level that is acceptable with regard to the consequences of 
Teteemaking the downgraded or sanitized information 
available. Many policymakers feel that a higher risk is 
acceptable ina tactical environment than is acceptable in 
a testing environment. Thus, any risk of operator or 
Simulator error might be considered unacceptable. The only 


apparent solution to this assessment is the simulation of 


the system By two or more independent tasks. One type of 
Memoee act SoeaS a2 Sink, accepting and acknowledging 
information at the higher level of protection. Another 


type of task generates representative information at the 
lower levels of protection, without any reference to the 
information received at higher levels of protection. The 
independence of the tasks means that there is no way to 
analyze any question which requires the flow of information 
through the simulated system, But a reasonable looking 
WeveclieeOtcmoack ground activity ean be generated for the 
loading of the network. This assists in the throughput 
analysis of other information transfer processes. 
rae Classification Collation 


There is another security issue which must be 


addressed on a case by case Hasis. Tris iS$s5 ue) 5s 
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puedes stb recatircs Sy collation. In these cases, a data base 
may be generated at a given classification level by 
collecting together a numbee of data items, all of which 
are individually elassified at lower levels. For example, 
mreotrtmation cegarding the I[ceathon and characteristics of 
asreeerndividual target, such as # railroad bridge, may be 
unclassified. AY Cae age cwlist -e€ontaining int ormation abour 
Meer PpOteMmtial targets in an area of op@rations is a 
Peter e rent matter. been entry “in the. dist eould bs 
Mme lassitrftfied;, but their coll&tion as a Single entity 
provides information which exceeds the collective content 
of the individual entries. An examination of the list as a 
Mimorre Provides as pieturé@ of the overall accuracy of the 
targeting assessment for tha avea and, by exelusion from 
the list, of any oversights in the process. Therefore, the 
target list would be classified at a higher level. The 
Besolution of this problem ts a classtc case of tradeoff 
analysis. ietewwe agen wecwt ry “pi the Vlsst is  prot@ctead at the 
level afforded to the list as awhole, it will not be 
available to the tasks which would normally have access to 
Pete, Dumeesaaition, the tesk which inittally generates the 
entry may not be authorized access to that level of 
mmitOorma tion. On tne ohare hand, treating the windividual 
entries at their own classification introduces the risk of 
Gomptromising the entire target list By allowing it to be 


collated one entry at a time at the artificially low level. 
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meerestated before, each oceurrence of classific@tion by 
Sotliliation must ae assessed individually. 
<0 Judgment 

It should be obvious that there is no simple or 
clearly right answer to the security problems inherent in 
command and control systems and thus aiso in their 
Simulation. Ultimately, the solution must rest with the 
Judgment of competent authority, based upon an assessment 


of benefit versus acceptability of risk. 


B. TIME SYNCHRONIZATION 

Mmvecigmout time discussion of the distributed simulation 
there has been an underlying, But never stated, assumpiicn 
that all of the tasks are essentially concurrent. Thera 
obviously must be some way to synchronize all of these 
tasks. Peecemiy lat 1 On task cannot Begrnm to compute che 
Dersuyit of a time or event step until ail inputs {rom 


previous steps have Been received from other tasxs. aan 


@re 
eeemese Vestal conceptual levels of SyncHrontzation, from 
Multitasking to event step. Only two are particularly 


unique to the distributed simulation approach. 


ie Master Clock 


Numerous techniques can Be utilized to synchronize 


Phew Vario0us tasks in a simulation. A large number use some 
sort of a master clock. This clock can be kept in terms of 
Simulation time, event number, step number, or a number of 
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migtgterent ceunters. TReeppt me pr ineiple as that the clock 
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Mines’  avatrlable yvariabWe "that synchronizes the task 
@racutions. This 168 a Simple concept in theory, but the 
use of real computers in a distributed environment makes 
Dayis 2 V@ry difficult concept to implement. The individual 
mookS MUSt be @ynchronized to the elock, a function which 
Mme addressed in section 2 below. inowaddrt:on, the clock 
must be available to each task, which means it must be 
logically avaiiable at each processor. If there ara ten 
BeepOGCeGessors, there are ten virtual views of the clock. 
synchronizing these views of the clock with each other will 


be addressad in section 3 below. 


ia SI¥nmnGhroniPging to Clock 





GCoansider Figure 22. Task 1 computes parameters to 
be passed to task 2. Assume that Both tasks are time step 
Simulations, with the time steps synchronized to coincide. 
—- Peta tase Wo each signal task S$ when they Rave 
Mompilieted g@reeessing for the current time step. Tasx 3 
then updates toe clock. Task 2 detects the clock update 
Siigsumpecrcmeactively or passively and computes the next 
imtervai This 15 Simple in theory, mostly because all of 
the discussion, and the underlying model, have been based 
toro n ti@e asstumption that tih¥ee results of task 1 are 
instantaneously transferred to task 2. Unfortunately, the 


transfer takes a finite amount of time that is a complex 


funetion of the amount of information to be transferred, 


84 





asi 





Clock 


| 
: 
| 
| 
: 


Task 3 


plbtive 22. lack Sunchrom zallon 


the data rate on the channel, and other processor and 
channel loading which must be multiplexed with the transfer 
mune tion. The problem becomes even mor2 complicatac when 
mei of thewinterface combinations discussed iff Sactton VII 
are considered. Qf utmost concern is the cade where the 
transfer of information is via a data base to data base 
interface across three separate processors. 

A lucky designer will Be able to implement some 
SOmrevnw OL ios it tive task handshaking, But shouldn't count on 
Clwiess SOmegtion rin too many cases. OtEteneesthe clock 15s 
specified in the initial functional requirements to be tied 


HOue  Wareeree tock” or real time. This is often necessary in 








ord@r to connect to manned simulators or tactical systems 
themselves, or to accurately assess human performance under 
loading and fatigue conditions. The result is an exception 
to the general rule of location independence for tasks. 
Careful consideration and analysis must be applied to 
processor loading and to the required bandwidth between 
tas ks . Tasks must then be allocated to processors in a 
Manner which will allow transfer delays to be limited to 
times which are acceptably small compared to the step times 
expected. 
oe Clock Synchronization 

As stated above, communications is not an 
Instantaneous process. Also, the delay between a given 
pair of tasks will vary with both time and the tasks 
eomorising the pair. If two tasks in separate processors 
both query a clock variable in a data base in a third 
processor at the same time, they may receive different 
values. This is because one of the requests takes longer 
than the other to reach the appropriate data bas@ access 
task. In addition, the responsesS are subjected to 
different delays and therefore, one of the times may be 
more accurate than tne other when ceceived by the original 
tasks. One example case will be used to show the 
eomiplezity of the problen. Detatiitenage ail of the 


possibilities is not possible. 
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The worst case arises whan the interprocessor 
delays are greater than the time step of the simulation. 
For example, consider the case where a tactical interface 
Mmemmeoe rung emonitored utilizing the TADIL 8B inter feace 
standard. The characteristics of this standard are such 
that the monitoring of the data axchainge must be time 


tagged to the nearest .001 second. The JINTACCS testbed, 


Pemieecime tests this standard, stretehes Erom Bedford, 
Peasssachusetts, to San Diego, Caiifornia, using leased 
commercial telephone Lines. The communications delays in 


Mmuemec i fe wits are much greater than the time step for the 
Syvotem ciock. The mastear clock in this example would be 
some function of real time. The delay cain be eliminated as 
a factor by keeping real time in each processor, along with 
the parameters that define the eurrent translation 
mune t 1 on. However, this approach assumes that the real 
times kept by the processors ara synchronized to within 
wuUGl second. Most computer system ciocks are guaranteed to 
remain within some deviation from the initially set time 
Petia sg@@eitied duration of sme. The problem thus reduces 
EeGmeome —Gre accurately ammtting @@eh clock at specified 
intervals. 

WWV radio receivers could Be used to receive the 
transmitted standard time signal. This approach suffers 
from two problems. Eir Steerieeer oeecosely to instail and 


Maintain receivers at a large number of sites which may 
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Pari leioate onilyw on an infrequent basis. Seconds, “tre 
receivers have oscillators and antennas. As such, ualess 
expensive precautions are taken, they become an 
unacceptable security risk due to undesired electromagnetic 
Doadiation. 

One solution is to arbitrarily designate one of the 
Smege ks aS correct. The system is then configured sc as to 
stabilize the delays as much as possible. Test messages 
are sent from the selected standard processor to each other 
Processor and returned until a confidence intervil is 
established for the round trip time. A message is then 
sent setting the remote clock to the current time pius half 
of the round trip delay. This message is also relayaa back 
Mamet ne Toriginalli processor in order to enstre against an 
abnormal delay during this message. This procedure works 
well it£& two assumptions can be satisfied. Pate Ss to we ame 
confidence interval must be sucn that the maximum possibie 
error in the one way delay time is less than the maximum 
aceentaS Met clock error. The second assumption is that the 
time delay is the same in botA directions. If not, a more 
comples set of test messages is necessary to estabiish 
geitays tag@each direction. Once the local clock has Seen 
set, local tasks use this clock for synchronization and the 
delay from the master processor is no longer a factor until 


the clock must be reset. 
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eS. SYSTEM VALIDATION 
In any introductory statistics course, someone will 
aiways ask how big a sample must be in order to be big 


enough. The same is true of the testing that is necessary 


to validate a simulation once it has been designed and 


implemented. There its always considerable debate as to how 
Much testing its enough. And, like the sampling question, 
there is no definitive answer. The test pmqwot simulators 


and simulations is a very subjective and political issue, 
for a number of reasons. 

Simulation validation is very expensive. Dien. og1 ca 
Serre cure Of a S@mulation can often be more complex than 
that of the system being simulated. This is due to the 
requirement t> simulate complex phenomenon, such as weapons 
affects, which are taken as a given in the real systems. 
Mmipeaeagd:ttion, thé simulation is interested itn not only 
generating ‘nea same decisions as the simulated system, but 
also in tracing the evolution of the decision. 

The reguit of validation ts not a piece of hardware, or 
Boao gqramsthnat can be utilized. Rather, it its some amount 
of confidence or doubt about the ability of the simulation 
to perform adequatealy. Ten € MC Oro tretra ctor and lack o€ 
Wammagtoeeeu results Ilwetd to th subjective nature of 
wat i dation. It is much like security in this manner. 
Ultimately, a commander must make an individual choice as 


to an acceptable and affordable level of validation. 
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Tcih@e M@atnm conceern with tAw distributed simulation i 


+) 


with the degree to which each task is validated. Ac mas 


premise has been that tasks could be utilised off the snelé 


from other simulations. Using a task implies 32 ca@rtain 
Meagree of confidence in it's functioning. This wust tbe 
based upon experience with the task, knowledge of th? 
Mevelooping organtzation, of some validatton process. 


Section [X will address configuration management within a 


network simulation community. It ts essential that thi 


aa 


Sentcitgqguration management effort track the vaiidation 
associated with each task so that reasonable design 


decistons can be made regarding the task. 
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Lo. MANAGEMENT CONSIDERATIONS 





A sound management policy is essential to any complex 
eomputer systen. In this section, several of the major 
eonsiderations for the management of a simulation network 


will be presented. 


a. ZONFIGURATION CONTROL 

Very few computer systems are static. The problems 
which the systems are designed to address often chRange. 
Ferhaps more often, the user of the system may change Ris 
menceeption of the prob lem. Documentation and configuration 
Manzgement are the tools by which dynamic growth of a 
system are effected. Before a system is modified it is 
assential that the current state of the system be known. 
And as changes evolve, they must be tracked, so that 
unintentional side effects can Be isolated at 3 later time. 

In Section 1, it was mentioned that the IFFN program 
was repeating development work done bBy the JINTACCS 
Program, and that the JINTACCS program had repeated 
development work done by the TACS/TADS progran. Witby? 
Among other reasons, both the JINTACCS program, and the 
TACS/TADS program "saved" development funds by cutting back 
on the documentation and configuration management aspects 


of their respective test systems. One might assume that 
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Cee IMportance of configuration management was not 
understood By the statfs of these programs. Yet both 
PEOgGrams had a2 primary misSion of managing the 
configuration management program for a Joint enureee of 
Staff directed interface among tactical command and control 
systems. 

The primary advantage to be gainad from a simulation 
metwork is tin the area of resource Shiring. Before an otf 
the shelf task can b@ incorporated into a developing 
Simulation, the simulatton dasgigqgner must be able to 
understand what the task does, and what the interface 
Specifications are. He must also be convinced that the 
Mmosk Willi ré@main availabie fer wisre. @His places a 
Somes tr duration management responsibilrty upon the 
Sreganaizat:iron which devetltopted the tsk initially. The 
Organization must orovide complete documentation concerning 
the function of the task, the assumptions which have been 
Somptlriedq, and the interface snoe@erifications. Ln 2d deer. on, 
the organization must Baseline tne task. A new "improved" 
WEE SiOMN Cannot be substituted for the task unless it 
continues to meet the needs cf the other organizations 
which are using the baseline version. 

A simulation network needs an active configuration 
Management plan. Many approaches to configuration 
Management have been shown to Be successful. Any which is 


agreed upon by the network participants is acceptable, 
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peovided that it baselines each task, provides a me@ethod far 


approving new versions, and tracks the users of each tazk 


BE. COMMUNITY ACCEPTABILITY 

In order to be useful, a network would have to be 
eecepted by ttre community which it is supposed to be 
serving. Past experience has shown that the Department of 
Defense is too fragmented, with too many loopholes, toa 
force standardization compliance on any of the services, or 
theirc majyor elements. A Look at past attempts to 
Standardize programming languages, culminating in the 
Beeent decision to thake ADA optional until it is acceptable 
to the user community, is a good example of how successful 
the “special case" argument can be. Therefore, a network 
will only be used seriously if it helps the using 
Seganizations accomplish their mission. The rest of this 
section is speculation, based upon experience, as to how 
meeceptabirlity esould be achievé€d in a simulation network. 

Initially, none of the major programs will share any of 
the assets available on a network. They have funds to 
develop unique systems, and a vested interest in producing 
Pooteuscmetemat are Not ceproducibBle By other organizations, 
Particularly those which might be reviewing the results. 
However, a few of the well established and less paranoid 
organizations will make their tasks available on a network, 


if one is established. Some of these tasks, most probably 
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those developed by the software support facilities within 
the services, wil! be documented in a usable manner. 
Analytical organizations within tne services have generally 
Been unable to afford large gimulations, particularly of 
tactical systems. AS a resuit, one or two will invest in 
access to the networet. Using the assets available on the 
network, and providing some ioca2z! tasks to customize the 
Sitmulations to their parsticuiar needs, will provide an 
affordable new and powerful tool! for use by these 
Organizations. 

These analytic organizations review and comment on the 
reports published by the major prograns. As their comments 
Become more detailed, and bettar supported, the tools which 
they are using will oe examined by the major program 
Managers. It ts unfortunate, but true, that much more time 
is spent throwing stones 4+ Sound analysis methodologies 
than in discussion of the resuits of the analysis. 

Mopeamerestmit rot this examination of the capabilities of 
the analytic organizations, the tntajor programs will begin 
to utilize the assats of the network in order to provide a 
capability to rapidly repeat and alter the tests conducted 
by the raviewing agencies There seems to be an 
Misti EWteromal rule at the jgoitint se@erviceg level that says 
that if a simulation can be shown to fairl under one set of 
assumptions , meet S fm vVdolad.  £{ Orsany other set of 


assumptions. A very common rebuttal technique when 
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Sevrewing the rcwmsults of aamimulation is to modify the 


assumptions, and show that the result with tie new 
assumptions is absurd. Thus, the original analysis must 
also be absurd. This may not be a very valid argument, but 
ezperience has shown that it is very prevalent. Correct or 
otherwise, it provides a powerful momentum for having 


access to the same tools which are being used to generate 
the original results. As a result, when the organizations 
with tight Budgets have accepted a network as a valid tool, 
the more affluent programs will accept the concept as a 


means of selt& dafianse. 


=e TACIT STANDARDIZATION 

As indicated above, efforts to enforce standardization 

e 

on operational military systems have not been particularly 
precessful . In this light, it would appear to be even lass 
Prmely to enforce a standardization of the tools used to 
develop and analyze these systems. Yet, the entire concept 
of the simulation network rests upon the standardizatz:zon of 
the interfaces among tasks. How can this parades be 
resolvad? 

The previous section presented speculation as to how a 
network might come to Be accepted By a community of users. 
If this premise is accepted, it follows that there will be 


one or more sets of tasks which comprise a core simulation 


with a family of tasks to customize this core to particular 


95 





meeplications. Sinee these tCasks woutd be written to 
Come rm 6G the Existing interfaces in the set of core 
tasks, these tasks comprise a tacit or de facto standard. 
The interface is controlled by the configuration management 
process and is "approved" by usage. 

The prime difference between these standards and an 
enforesd standard is that enforced standards require the 
foresight to develop the standard prior to development of 
the tasks to he supported. The de facto standard is an 
evolutironary result of the usefulness of a particular set 
oe tasks. There are numerous examples of de facto 
standards in beth industry and the military. 

The uUP/M operating system for microcomputers is not a 
pPparticuiarly elegant, nor efficient, operating system. 
Yet, :t was useful and avairlable and became widespread. 
The large amount of supporting software that was developed 
LSiINng it westadslished a de facto standard for commercial 
software written for 8080 family microcomputers. 

The ARPANET provides an example within the military. 
There 2r# numerous editors available on the network. 
Several ot the more useful have been utilized as callable 
tasks by other processes, such as message handiers, and as 
front end processors for text formatting programs. These 
Bro gtame linkages anddependenecwves Corm a de facto 
Standardization on a distributed network. In this case, 


the community which has embraced this standard has a number 
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of diverging mission areas. But, the etandard is useful, 


and therefore it has survived. 


D. SCHEDULING 

One of the greatest problems in the simulation of 
command and control networks 18 scheduiing. Several of the 
organizations which have the major assets, Particularly the 
manned simulators, are working three shifts a day. The use 
of a network probably will not alleviate the wo::k Load on 
these simulators. The only savings to be gainet]d would be 
Mnmemecre@ing of the simulator when another form of 
Simulation, previously unavailable, acouid satisfy the 
Peagurrements of 3s particular test. However, this would be 
offset by the requests from organizations which previously 
did not have access to the simulator. 

There 1s one cas@ in which the natworik could provide 
some relief on tight schedules. A given simulation task 
can often be conducted at any of Several sites. 2 ees 
applies to Bo0th the manned simulators, which are often 
srtuated at Both development and training srtes, and to 
eomputerc programs, which could run on any 2£ a number of 
Smt .atecontigqurations . Typically Rowaver, they are only 
Euine im some Location. This is because only one location has 
the analysts and test control personnel to supervise the 
test and dissect the results. Using a network, the logical 


avarlaBrilirty and connectivity of a task are not dependent 
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Upon LtS phystocal Location. Thus, tt becomes possible to 
relocate a given task to a new site, with no analytical 
GCmpability loss. There is an impact on test control only 
if a controller must be physically Located with a test 


participant due to the nature of the simulation. 
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ae SUMMARY 


RBRis sPetran will present a short summary of the 
Important requitaments for a distributed network to support 
command and control network simulations, and some personal 


comments regarding tha methodology. 


Ae REVIEW OF REQUIREMENTS 


Although the methodology presented in this thesis can 


have very powerful results, it is reasonably simple in 
Sonces t . Therefore, there are very few hard requirements 
feos tmp le men’;a lion. The following items are the key 


requirements prasented in the previous sections. 

ee The precescsing nodes in a command and control 
network should be model2d as separate systems without any 
assumptions abdout the actual source of input information or 
Heiser ma tt on Of ogrtput information. This allows the level 
of detail in the simulation, and the configuration of the 
Simulated network to be varied without tmpact on the 
individual node simulations. 

a All simulation tasks should communicate via an 
interface process. This process resides at the utility 
program or operating system level of the host architecture. 
As such, it has access to all of the [/0O capabilities of 


the host machine. 


Seed 





oi The tinterface process is Segmented inte primary and 
Se@ondary tas ks’. The primary tasks are essential ts the 
function of the process, and are bound te gach other at the 
time of creation. The secondary tasks tailor the interface 
Process to the individual requirements of 4&4 JQgiven 
simulation. 

2 Only the primary tasks must b2® replicat2ad tan each 
Pea Orce@ sts lt mg nade in ordé@r to support a distrit‘sted 
arehitecture. 

ome Individual tasks send data to logical addjress 
Mos, not to specific tasks. The address list associated 
with a task‘s channel of communication is established when 
the channel is opened and remains constant. 

Go. Entries in address lists may be dynamically changed 
Gegerei Tg tive @wecution of a simulation. Address lists 
Pfommecar 1 tne Logical names of the task input channels 
designated to receive data sent to the address Jist. 

ee The primary tasks within the interface process are 
responsiBle for translating Logical channel names into 
communication paths with physical tasks. The primary t2sks 
are the only tasks aware of the relationship Satween 
address Lists and logical names, and Between logical names 
and physical channels. 

8. Several issues to be resolved by simulation 
developers, such as security, will be major factors in the 


usability of the network By a large community of users. 
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va Digicom Loma nao onfEigwration management ere 
adsolutely vital to the degree to which network resources 
aire sharable. 

0 ee Standardization should evolve as a function of 
task usefulness, rather than being imposed as an entry 


Gondition. 


Be COMMENTS 

The methodology for the implementation of the interface 
Process which has Been presented in this thesis has been 
addressed from the point of view of Supporting the 
Simulation of command and control networks. However, it is 
really avery general system concept. As such, it appears 
to Be useful in a large number of networking environments 
where distributed tasks must act cooperatively. Eo.5 
instance, consider a distributed information management 
system. One of the major problems to be addressed has 
alwavs been how to cope with a dynamic network 
Mom gimatiom SO that information reporting, collating, of 
retrieval processes know where data bases are. Several 
prototypes simply give each process a list of alternative 
locations to be searched in order to locate the data base. 
A much simpler approach might be to use logical names for 
the data base access tasks and allow an interface process 
wOmece sO. Veumcnm Location prob lem. Up@aeting a ilogteal da tga 


base with new or changed data is also simplified, since the 
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dynamic nature ot the address list allows multiple updates 
from a process as a@asily as a Zingle update. And, the data 
Capture capabilities accommodate “the requirement to save 
copies of transactions for recovery and reconstitution 
purposes. 

Several people who have reviewed draft copies of 
portions of this thesis R2ve asked questions such as “How 
Woultd the tasks associated with thee simulation of .. . be 
distributed across the network?" This thesis has attempted 
to specifically avotd addressing that type of question. 
This policy is not because cf the difficulty of answering 
Plemauest ion, ar:rthougnh it is a difflieult question. Rather 
it is a matter of the proper perspective on the purpose of 
the thesis. The purpose of the thesis was to present a 
Simulation environment that would support a distributed 
implementation with the sharing of resources. Hopefuily, 
Pet Ppdoes. so. However, while it is important that the 
Sige@ifcledwlon address all asgects of importance, it is also 
essential that it not be overspecified. This environment 
is designed to help the simulation designer by extending 
PitecmOpDtCtomGmavailabie to him. An attempt to answer issues 
such as that above would only serve to place artificial 
Timits on application techniques utilized. 

For the same reason, I have failed to address the 
issues of how the primary tasks should communicate with the 


secondary tasks, and how the interprocessor communications 
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should be managed. NegewWEENGr tissue impacts on the basic 
Seoncep te . Any method which makes sense for the particular 


equipment configuration utilized will support the concept. 
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